身為一個軟體工程師,我想你對這個場景肯定不陌生:你信心滿滿地提交了一個 Pull Request (PR),然後......就沒有然後了。
時間一天天過去,你的 PR 就像被遺忘在數位世界的孤島。
於是,你開始了每天的例行公事:
在團隊的 Slack 頻道上,禮貌性地 tag 同事:「哈囉,有空可以幫忙 review 一下這個 PR 嗎?🙏」
在 PR 的描述裡,補充更多的細節,深怕別人看不懂。
最不得已的時候,你可能會直接走到同事的座位旁,展開「溫情攻勢」,直到他打開你的 PR 頁面。
看起來問題解決了,對吧?你的 PR 終於被合併了。
但詭異的是,下週,下下週,同樣的戲碼不斷上演。
你發現自己花了大量的時間在「提醒」和「等待」上,而不是在創造價值。
我們好像解決了眼前的這個 PR,卻從未解決「PR 總是沒人理」這個根本問題。
我在書中找到了脈絡《本質思考:MIT菁英這樣找到問題根源,解決困境》,才一語驚醒夢中人。
我們沾沾自喜的「解決方案」,其實都只是在「治標」,從未觸及「治本」。
《本質思考》開篇就拋出一個尖銳的問題:「為什麼思考了之後,還是會出現解決不了問題的爛答案?」
作者平井孝雄直指要害:「因為,人並不會深入思考。」
我們的大腦天生傾向於節省能量,喜歡走捷徑。
當面對問題時,我們下意識會選擇最直覺、最省力的方式去應對,而不是花費心力去挖掘冰山下的真正原因。
作者將這些阻礙我們看清問題本質的思維捷徑,歸納為九個「思考慣性」。
這九個思考慣性,就像九個思想上的陷阱,讓我們在問題的表層不斷打轉。
這是最經典的「頭痛醫頭,腳痛醫腳」。
看到 Bug → 二話不說,修復 Bug
看到網站性能變慢 → 立刻想辦法優化單一查詢
看到團隊成員吵架 → 趕快當和事佬,調解衝突
這種思維只專注於消除「症狀」,卻沒想過症狀背後的原因。
Bug 為何會產生?是流程問題還是能力問題?網站變慢是架構問題還是流量暴增?
習慣將問題簡化為「單一因果關係」。
Code Review 慢 → 一定是同事太忙了。
專案延遲 → 一定是時程估算不準確。
團隊效率低 → 一定是我們用的專案管理工具不夠好。
但真實世界是複雜的系統,問題往往是多個因素互相影響的結果,而不是一條直線。
在壓力下,我們總想找到「速效藥」。
遇到技術難題 → 馬上到 Stack Overflow 複製貼上最高票的答案,不管適不適合。
遇到流程問題 → 選擇最簡單的修補方式,例如「我們多開個會吧!」
結果:飲鴆止渴,暫時緩解了焦慮,卻埋下了更大的技術債或管理債。
「如果不能一次性完美解決,那就先不要動。」
因為害怕方案不夠周全,或擔心改動會引發新問題,結果在過度的規劃與分析中錯失了解決問題的時機,導致問題惡化。
面對多個選項時,陷入無止境的分析與比較,遲遲無法下決定。
要選 Vue 還是 React?
要用微服務還是單體架構?
A/B Test 的數據要收集到多精確才能做決策?
過度分析導致行動癱瘓,這本身就是一種糟糕的決策。
過度依賴過去的成功經驗。
「我以前都是這樣做的,沒問題啊!」這句話是不是很耳熟?但市場在變、技術在變、團隊在變,用舊地圖是找不到新大陸的。
盲目地追隨「業界最佳實踐」或「大廠解決方案」。
Google 用了微服務,我們就該用嗎?Netflix 做了混沌工程,我們需要嗎?
不經獨立思考,直接照搬權威的答案,往往會水土不服。
決策不是基於客觀分析,而是個人好惡。
「我就是不喜歡這個框架!」
「我覺得那個同事的提案很有問題!」
當情緒主導了判斷,我們就離問題的本質越來越遠。
我們的大腦天生就有許多 Bug。
例如「確認偏誤」,只看見支持自己觀點的證據;或是「從眾效應」,因為大家都這麼做,所以就跟著做。
不了解這些偏誤,我們就會在不自覺中做出有偏差的判斷。
讀完這九個思考陷阱後,我背後一陣冷汗,發現自己幾乎每個都中招了。
回頭看那個讓我困擾已久的「Code Review 拖很久」的問題,我的所有「解決方案」,完美地體現了前三種思考慣性:
症狀導向思維:看到 Review 慢(症狀),就去提醒(處理症狀)。
線性思維:我認定 Review 慢的原因「就是」同事太忙。
急於求成:我的方法(提醒、催促)是最快、最直接的,但也是最沒用的。
結果就是問題暫時被「處理」了,但根本原因:
「為什麼大家不願意或沒時間做 Code Review?」
「現行的激勵機制是否忽略了 Code Review 的價值?」
「我們的流程設計是否讓 Review 變得困難?」
——這些深層次的問題,從來沒有被觸及。
於是,我只能日復一日地扮演那個「PR 提醒小天使」的角色,耗費心力,卻沒有帶來任何實質的改變。
意識到自己身處陷阱,是走出陷阱的第一步。這九個思考慣性,就像一份「思維體檢表」,幫助我們診斷出自己在解決問題時的盲點。
除了知道了「為什麼我們做不好?」之外,更關鍵的問題是:「那要如何才能做好?」
要真正做到「治本」,我們需要一套系統性的框架來透視問題的本質,找到藏在冰山下的結構性原因。
在下一篇文章中,我們將一起探討《本質思考》的核心武器——來自 MIT 的「模式」與「物力論」思考法,學習如何像偵探一樣,從混亂的現象中,剝絲抽繭,找到問題的真正根源。
#本質思考 #問題解決 #系統思維 #根本原因 #深度思考 #軟體開發 #ITHome